Current peer to peer (hereinafter—P2P) download and streaming systems are unaware of the media and transport layer characteristics of the payload they are carrying. Furthermore, they bear several restrictions in their design that disallows content alteration to take place at intermediate nodes.
P2P is gradually becoming an efficient alternative to deliver content and video to end-users. Most early P2P implementations were able to support file download only. In these systems, the asset is sliced at the point of ingest into many file chunks of a pre-defined size, each chunk is hashed to produce its hash value, and a metadata file is created (including a dictionary of all chunk hash values). The metadata file is typically distributed to a centralized server (typically called a tracker) and to web servers.
Users discover about the existence of a P2P asset by external means such as websites and search engines, and are directed to the aforementioned metadata file. With the information at the metadata file, they contact the tracker and effectively become part of that asset torrent or swarm. The tracker of the asset is constantly collecting report data about each of the users (peers) of the torrent, including who is currently connected and what parts of the asset they are in possession of. The tracker is also responsible for providing any requesting peer with a list (a subset) of other peers in that torrent.
Peers engage in chunks transfer governed by some transfer algorithms; chunks are typically transferred using protocols such as TCP/IP. Since there are no real-time constraints requiring chunks to arrive at any given specific order, the algorithms usually try to create a uniform spread of all chunks between the swarm users, thus providing a better distribution rate for the file.
Recently, some new methods were introduced into existing system, in a way which eliminates the need for a centralized tracker, and instead distributes the tracking function between the peers themselves, using techniques such as Distributed Hash Tables (DHT).
A new breed of P2P system is now becoming popular. These systems allow a linear TV viewing experience; i.e. users are tuning into channels and are provided with a constant stream of video. The actual implementation varies from one vendor to another. Some systems such as PPLive, use protocols like BitTorrent which were originally designed for file download, with some extensions that allow it to work within the time constraints of streaming. Other popular systems such as Joost and Babelgum use proprietary methods whose details are non-public. These systems, however, are considered to be using some hybrid of server infrastructure and peers intelligence to work.
P2P quality-of-experience (QoE) is far from optimal today since traffic is usually transferred as a best-effort Quality of Service (QoS) class and packets are typically dropped or delayed in the face of network congested links, thus seriously severing the smooth viewing experience expected from a video service. Current implementations usually rely on more bandwidth and TCP/IP retransmission algorithm to eventually deliver the traffic to the end-user; while this is a valid approach for download, it has little value for streaming.
What is needed is a system and protocols which are more dynamic in nature, in a way that allows it to apply various techniques of real-time content alteration to overcome network congestion as they appear. Some of these techniques change content by reducing its size and bitrate through rate-shaping algorithms, while others like Forward Error Correction (FEC) introduce overhead to the packet, to allow it to be reconstructed at the receiving end. These technologies are known and in use in traditional broadcast and IPTV systems, however they have never been designed in a P2P environment.
There are several elements in the current system design that currently disallow these operations, as such:
Video awareness in the protocol and architecture level—current P2P streaming pay very little attention to the nature of the payload they distribute and as a result they provide poor utilization in terms of network resources and user experience. The video which is carried within the P2P packets has a known structure and some unique characteristics. Few such examples are I, B, P frames hierarchy, GOP size and structure, video clock information, metadata tables and layers in Scalable Video Coding profile. This unawareness of video, restricts systems in applying real-time video processing to P2P traffic.
No video semantics—another limit of current P2P streaming is that it makes the assumption that equality between two frames of video on separate clients (e.g. 2 users watching the same scene in the same channel) entails two identical bit structures. This is however, known not to be the case. For example, a frame might be quality-degraded or trans-coded while it still semantically bears the same meaning.
As a direct result of the previous statement, P2P hashing mechanism is inadequate for the delivery of video, since current hash implementations, take the assumption that 2 semantically equal frames will have the same bit structure and hence the same hash value. This entails, that any alteration to a transfer unit in the P2P schema, will cause damage to its hash consistency resulting in its purge at the receiving end-point.
Lastly, current systems apply a single dimensional indexing system for accessing transfer units (chunks). For example, a client can ask for only one representation or version of a transfer unit. In order to allow, multiple versions (such as different bitrates) of the same unit to co-exist there is a need for a better multi-dimensional indexing system.